Article Outline
TOC
Collection Outline
[TOC]
使用案例：使用WSO2 Identity Server构建安全身份框架
作者： Dimuthu Leelarathne
2016年9月6日
介绍
组织通常处理不同类型的身份，例如客户，合作伙伴，子公司的员工，甚至是科技公司的开源社区。 手头的任务是能够使用安全身份系统有效地管理这些多重身份。WSO2也有这些确切的要求，因此我们考虑使用WSO2 Identity Server （WSO2 IS）设计和实现最先进的安全身份和访问管理（IAM）框架。 该用例将解释我们如何开发和实施此框架以及为组织提供的好处。
关键架构目标和挑战
WSO2的身份框架在过去10年中逐步发展，满足各种需求并坚持IT团队确定的最佳实践。 在开始这个项目之前，WSO2在一个LDAP中维护了它的所有身份。 大多数系统都连接到此用于身份验证和授权，因此用户可以在大多数系统中使用相同的用户名/密码， 但是系统之间没有单点登录（SSO）。
实施身份管理和SSO的最佳实践 - 引入和利用WSO2 IS的优势的总体目标是遵循最佳实践并最大限度地减少对WSO2身份基础架构的威胁。 新IAM框架的直接好处是将SSO引入所有系统，即员工将SSO引入所有授权的内部和外部系统，外部用户将访问所有授权的外部系统。 这将基于WSO2 IS。
管理身份/应用程序配置 - WSO2的基础架构团队负责管理WSO2生态系统中的所有身份。 该团队提供用户帐户，管理授权，取消配置用户帐户，并管理所有系统中所有与身份相关的配置。 新系统旨在集中员工身份管理，从而使其更易于管理，并为外部身份管理基础架构提供透明。 该框架的另一个关键方面是开发基于WSO2 IS的集中配置应用程序。
实施双因素身份验证 - Gmail和Google应用程序的双因素身份验证是IAM框架的另一个目标。 电子邮件访问需要高度安全且可用，因为它是WSO2内的主要通信模式。这是内部员工的关键任务系统。 有些员工使用Gmail提供的多重身份验证，而有些员工则在浏览器中保存了Gmail密码，导致泄密。 为避免所有这些问题，需要为Google应用提供双因素身份验证。
管理开源社区的身份 - 以前的体系结构的另一个缺点是开源社区成员的身份绑定到用户的电子邮件地址。 如果用户丢失了他们的电子邮件地址，他/她的身份会发生变化，即所有JIRA活动都将被删除。 使用UUID作为LDAP中的用户名将允许这些开源用户保持相同的身份，即使他们需要随时更改某些属性。
WSO2 IS部署之前的身份基础结构
以前，WSO2在一个LDAP中保留了所有身份。 大多数系统都连接到此LDAP以进行身份验证/授权。 每当应用程序需要时，此LDAP在不同区域/网络之间同步（图1）。
图1：部署WSO2 IS之前的身份基础结构
Google应用和其他云服务（例如人力资源系统和ERP系统）可以定期同步LDAP。 但是，根据公司政策，WSO2 LDAP密码未在WSO2 Infra团队的控制域之外同步。 因此，员工必须分别为Google应用和其他云服务维护密码。 因此，所有基于云的应用程序都有自己的凭据，这要求员工记住几个密码以访问各种企业系统。
提出的解决方案架构
在单个LDAP中维护所有身份被确定为先前体系结构中的主要弱点之一，因为为内部和外部用户维护两个单独的用户存储是最佳实践。
员工身份和外部身份具有不同的特征。 客户身份是分布式身份，可以来自社交网络和自我注册的属性，并且该身份的控制权归客户所有。 客户身份的规模可以显着增长，重点是由市场需求驱动的个人和用户体验，从而导致自我注册和自我维护的配置文件。 在WSO2生态系统中，外部用户包括客户，合作伙伴和开源社区。
WSO2员工身份存于组织联系在一起。它具有中心控制的特征，而不是属于客户的客户身份。 员工身份在一个人加入组织时开始，并在他/她的雇佣合同终止时结束。 它已经经过校验和验证。
遵循行业最佳实践，决定在两个独立的IAM框架中维护这两种类型的身份。 这可能意味着两个凭证存储和两个身份服务器，或一个凭证存储和两个身份服务器。 但我们决定将两个身份程序完全分开，从而产生图2所示的体系结构，该架构中有两个独立的IdP，其中有两个分别用于外部和内部用户的LDAP。
图2 - 使用WSO2 IS建议的身份基础设施
要实现上述体系结构，需要重新构建当前的LDAP。 员工将在一个LDAP上，外部用户将在一个单独的LDAP中。 基于这两个凭证存储，将有两个单独的WSO2 IS部署。
- 员工使用的所有系统都配置为内部IS中的服务提供者
- 所有面向外部的系统都配置为外部IS中的服务提供者
- 员工现在如何访问面向外部的系统？ 这将通过外部和内部IS之间的身份联合来完成，使用WSO2 IS身份总线功能。 只要员工收到登录请求，外部IdP就会向内部IS生成出站身份验证请求（图3）。
图3
下表描述了WSO2的应用程序组合：
| 应用名称 | 描述 | 主IdP | 用户配置 | 角色管理 | 云/预置 |
|---|---|---|---|---|---|
| APPM | WSO2的应用程序门户 | 内部 | Prov app | LDAP | 预置 |
| Salesforce | WSO2的CRM | 内部 | 手动 | 在app内 | 公共云 |
| Concur | 差旅费管理 | 内部 | 手动 | 在app内 | 公共云 |
| HR系统 | WSO2的人力资源管理 | 内部 | Prov app | 在app内 | 公共云 |
| Google应用 | WSO2的商业应用程序 | 内部 | Prov app | 在app内 | 公共云 |
| Redmine | WSO2产品的项目管理 | 内部 | Prov app | LDAP | 预置 |
| NetSuite | WSO2的ERP | 内部 | Prov app | 在app内 | 公共云 |
| Support portal | 支持客户端配置工具。定制应用程序。 | 内部 | 手动 | LDAP | WSO2云 |
| PMT | 补丁管理系统。 定制应用程序。 | 内部 | Prov app | LDAP | 预置 |
| Confluence | 维基托管文档 | 内部 | 手动 | 在app内 | 预置 |
| WiFi | WSO2的WiFi | 没有 | Prov app | LDAP | 预置 |
| Internal SVN | 带修复的代码 | 内部 | 手动 | 在app内 | 预置 |
| OT Jira | 开源JIRA | 外部 | 外部用户的JIT | 在app内 | |
| 支持JIRA | 客户在线支持系统 | 外部 | 支持门户 | 在app内 | 预置 |
| Certificate partner portal | 定制应用程序 | 外部 | 手动 | 在app内 | 预置 |
| wso2.com/Drupal | wso2.com网站 | 外部 | 具有角色的外部用户/应用程序的JIT | 在app内 | 预置 |
就开源社区而言，代码是另一个重要方面。 代码在GitHub中维护，WSO2使用的订阅包不允许身份集成。
配置和访问控制
应用程序要求配置用户并实施适当的访问控制策略。 WSO2中的应用程序组合使用RBAC。 不同的应用程序需要不同的角色和用户组进行授权。 在以前的体系结构中，用户组尽可能在LDAP中为不同的应用程序创建。 如果不可能的话，他们就只会在应用程序中维护。
WSO2 IS有一个全面的框架，允许在用户首次登录（JIT）和/或用户添加时为其他应用程序配置用户（图4）。 它还可以将用户配置到其用户存储，这称为入站配置。WSO2用例的关键需求是出站配置。 配置用户的插件组件称为配置适配器。 开箱即用的配置适配器包括SCIM，SPML，Google应用和Salesforce。
图4
内部应用： 基于云的系统配置可以通过将适配器写入WSO2 IS来完成，无需手动执行。 在跨不同域配置用户时，这是最佳做法。 决定为所有内部部署应用程序保留现有的LDAP同步基础结构。 对于每个内部应用程序，用户组定义为BU和应用组。
外部应用： 对外部应用程序的授权和配置需要做更多工作，因为外部各方和员工都需要登录外部应用程序。 员工在外部应用程序中具有特殊权限，例如管理员权限，例如，员工将能够在JIRA系统中管理项目，而外部用户只能创建票证，评论和解决问题。 员工用户组在内部LDAP创建，外部用户组在外部LDAP中创建。 只要应用程序能够处理多个LDAP，就会将这些LDAP配置到应用程序并正确配置授权。 WSO2支持门户就是一个这样的系统，其中两个组都被分配。
Google应用和多因素身份验证（MFA）
新IAM框架的目标之一是为Google应用提供MFA。 验证的第一个因素是用户名/密码。 选择第二个认证因素作为SMSOTP。 如果一个人忘记他/她的手机会怎么样？ 提供一组备份码供下载。
WSO2 IS身份验证框架具有MFA方案的步骤身份验证。 可以通过“AND”操作连接无限数量的步骤，并且每个步骤中的验证器之间通过“OR”操作连接。 对于WSO2，身份验证的第一步是用户名/密码，第二步是SMSOTP。 如果用户会话已经完成了第一步，那么只有第二步将呈现给最终用户（图5）。
图5
个人资料更新
WSO2员工将使用WSO2 IS仪表板更新其配置文件。 这允许他们管理他们的个人资料信息，包括MFA偏好设置，例如添加/修改FIDO（Fast IDentity Online）设备以及通过访问他们的个人资料下载备份码。 外部用户可以通过wso2.com网站更新配置文件，该网站调用外部IS的SCIM API来更新属性值，如图2架构图所示。
该体系结构的另一个主要目标是使开源社区能够更改其电子邮件地址并仍保留其开源活动的历史记录。 让我们考虑由WSO2托管的开源社区应用程序，它是一个JIRA。对于开源JIRA，UUID将配置为用户名。 这允许用户更改其电子邮件地址但保留活动历史记录。
部署架构
将有两个身份服务器群集 ：一个用于内部，另一个用于外部。 内部身份服务器部署在AWS中的两个可用区域中完成（图6）。 每个可用区域都有2个身份服务器配置为主动/主动模式，没有状态复制。 在每一层，IP散列用于“会话管理”。 它与使用的协议很好地协同工作是SAML2.0。
图6
数据库按以下方式同步：
- RegDB - RDS多区域同步
- User DB - RDS多区域同步
- 身份 DB - 不含会话表的主从同步。 不应同步会话表，因为不应覆盖会话ID，否则会导致现有用户会话将无效。
外部IS部署将遵循相同的模型。
现状和前景
作为项目的第一阶段，内部身份服务器部署已完成。 SSO已针对所有内部应用程序配置，并且Google应用程序MFA也已实施。 该团队现在正在重组LDAP。 该项目的后续步骤是部署外部IdP并为外部应用程序配置SSO。
成功实施第1阶段后，所有WSO2员工都使用WSO2 IS登录其应用程序。 它为员工提供高效，轻松的用户体验，为所有用户提供一键式应用商店（图7）。
图7
在阶段2中，WSO2的外部社区将受益于能够在不同系统之间进行SSO并更改其所有身份属性（包括其电子邮件地址）。
结论
在此项目之前，WSO2在同一LDAP中维护所有身份标识。 如上所述，这不是最佳做法，而是通过建立两个具有两个IDP的LDAP来解决。 现在所有内部系统都连接到一个LDAP，而SSO由WSO2 IS提供。 使用设计的配置应用程序可以轻松配置和帐户管理。 一旦建立了外部LDAP，外部各方（如开源社区，合作伙伴和客户）也将享受SSO和独立于其属性的身份。